1. Field of the Invention
Embodiments of this invention relate generally to operating systems and computer system architecture, and more specifically to improving system concurrence and providing additional system functionality by decoupling core operating system functions.
2. Related Art
In all but the most simplistic of computing applications, some form of operating system (OS) is present on a computing platform in order for that platform to function. The type of platform can vary greatly: for instance, desktop computers and network servers run operating systems in order to operate, but, for example, cell phones, personal digital assistants (PDAs), complex calculators, and automated teller machines (ATMs) also require an OS. And while the features made available to the user through an OS will vary significantly depending upon the platform in question, there is some commonality of function between every functional OS. In particular, every OS generally serves as the interface between the central processing unit (CPU) and the rest of the computer system.
In order for the computing system to function, the OS provides two fundamental functions. First, the OS functions as a scheduler for the CPU, in that tasks for the CPU to perform must be channeled to the CPU in a logical fashion; inherent in this function is translation, as not all CPUs have the same instruction set, i.e., accept the same instructions, and so the OS translates requests into a syntax the CPU understands. This first function is what forces an OS to be platform-specific, as supporting a different type of CPU requires supporting a different instruction set.
The second function of an OS is to be a services broker for the computing system. Applications running on the computing system, or devices connected to the system, do not need to know exactly what services are available on the system, nor exactly how to interface with the hardware resources present in the system; instead, such applications and devices need only communicate with the OS, which can forward requests to hardware or other applications as appropriate. For example, if a computer program running on the system calls for a sound to be played, the program need not know the make or model of the soundcard installed in the system, but simply tells the OS that a sound should be played; the OS will instruct the soundcard accordingly.
This concept is illustrated more fully with reference to FIG. 1A. FIG. 1A depicts a simplified overview of a prior art computer system 100. Computer system 100 is depicted as being divided into three distinct levels: application software 110, operating system (OS) 120, and hardware resources 160, which includes the central processing unit (CPU) 130, memory 140, and soundcard 150. In order to function application 110 needs to access several system resources; for this example, request 113 will be a request for a computational process to be performed and the results returned, and request 116 will be a request for a sound to be played on soundcard 150. Application 110 issues request 113 and request 116 to OS 120. In some cases, OS 120 would include application program interfaces (APIs) such as API 121 and API 123, which provide standardized handling of certain types of requests from applications like application 110. OS 120 interfaces with some hardware through the use of device drivers, such as driver 125; device drivers are specific to the piece of hardware they are associated with, and provide OS 120 with information on how to interact with that piece of hardware. In present computer systems like computer system 100, OS 120 is written to interact with a particular CPU 130 (or, at best, a class of CPUs corresponding to certain common specifications, such as x86 compatible processors), and no device driver is necessary; the functionality necessary to interact with CPU 130 (and related resources like memory 140) are integrated into OS 120.
Several limitations are inherent to this common method of computer system design. First, as noted above, OS 120 includes the scheduler and instruction set for CPU 130. In many cases, the OS is actually optimized around a particular instruction set. As a result, most operating systems can only run on a single brand or family of processor, e.g., x86. And because application software is written to interact with the APIs of a particular OS, applications can only run on a single brand or family or processor.
A second limitation results from the duplication of effort caused by the OS itself. With reference to FIG. 1B, an example application request cycle is depicted. In step 175, at the moment when application 110 sent request 116, requesting that a sound be played, application 110 was resident in memory and performing operations on the CPU. In order for OS 120 to respond to request 116, in step 180 application 110 must suspend operations in order to allow OS 120 to access CPU 130. In step 185, OS 120 processes the request. In step 190, after request 116 is handled, OS 120 calls soundcard 150 and instructs that a given sound be played. Finally, in step 195, OS 120 suspends again and application 110 can resume executing operations on CPU 130. Essentially, the same request must be issued twice, once by application 110 and once by OS 120, before the desired effect occurs; this duplication of effort requires more CPU cycles than simply issuing an instruction once would. In a desktop computer, for example, such CPU switching functions occur extremely frequently. This duplication is traditionally an accepted limitation, as bypassing OS 120 would require every application to include the instruction set for every conceivable hardware device. OS 120, acting as a services broker, reduces the development cost of application 110, at the cost of reduced CPU efficiency.
A third limitation is inherent to the prior art approach to system architecture within computing systems. In existing computer systems, running prior art operating systems, such as OS 120, all or substantially all information transfer between devices in the computer system occurs over a single common bus, commonly referred to as a multi-drop parallel bus. As all attached devices must share this common bus, a bottleneck in data transfers exists. Continuing the example from above, when application 110 requests that a sound be played, and OS 120 passes that request to soundcard 150, a portion of the available bandwidth on the common bus is used, which reduces the available bandwidth for other operations within computer system 100.
It would be advantageous for a system to address some or all of the above limitations.